Many vendors of computer hardware and software provide support for returning components that are suspected of being defective. Unfortunately, it can be difficult to properly identify a defective component. As a result, it is often the case that non-defective components are returned. This results in significant costs for the vendor because the vendor must ship the non-defective component back to the customer, or they may have already shipped a replacement component under warranty when in fact the original part was not defective. In order to reduce the return of non-defective components, a vendor may require a diagnostic code before a return will be accepted.
In order to obtain a diagnostic code, the customer may run diagnostic software themselves, or call a vendor's technical support representative to receive help in identifying a problem component. Diagnostic software can be an aid in identifying defective parts, but such diagnostic software must be used properly. Diagnostic software can take a long time to run due to the number of components that must be tested. Keeping a customer on the phone while the diagnostic program runs, while necessary, may irritate the customer. In addition, waiting for the diagnostic program to run may have an impact on the technical support representative's apparent productivity, as they cannot deal with other customers while waiting. As a result, there is a temptation for a vendor's technical support representative to guess at what might be failing rather than waiting for the diagnostic program to run its course. The technical support representative may then provide a known, perhaps previously used, valid diagnostic code that supports the representative's guess, without waiting for, or even running, the diagnostic software. Thus while the customer's wait time may be reduced, there can still be a significant number of unnecessary returns of non-defective components when the representative's guess is wrong.
As a result, there is a need in the art for the present invention.